There is a chance this can cause a regression on HDZero osd.

This was added in the past because it sped up the osd update for hdzero if the user kept to the 4:3 aread of the screen.

I believe this is no longer an issue recent hdzero firmware when paired with INAV 6+.

A better solution for this may be to add a dedicated option for SD osd in hdzero, while removing this auto detection or eventually suppoting auto negotiation of canvas size, like betaflight.

Please remove this pull request. The low res OSD is pretty important for people that want fast OSD refresh rate.

This will negatively affect a lot of users based on my recollection of AHI refresh rate complaints before this was released.

@geoffsim I think knows the code implementation the best.

Please remove this pull request. The low res OSD is pretty important for people that want fast OSD refresh rate.

This will negatively affect a lot of users based on my recollection of AHI refresh rate complaints before this was released.

@geoffsim I think knows the code implementation the best.

It is not decided yet if this is making it into 8.0. Probably not. But I will look into removing the special case and maybe adding an explicit small osd canvas option to hdzero in 8.1. If we go around by the rumors, we are likely going to need new options for DJI O4 as well.

The OSD code has changed quite a bit since I originally submitted the first release, so please don’t consider me an expert in this area any more.
The original slow refresh rate was never a INav issue, but was due to a bottleneck in the VTX/VRX comms. The comms channel that transmits the OSD from the VTX to the VRX has a finite bandwidth and can only transmit about four full 80*50 frames per second. This was partially alleviated in the VTX code by detecting if an OSD frame was wholly within a smaller frame of the HD canvas and then only sending that smaller frame to the VRX, resulting in a faster refresh rate of about eight frames per second.
As the VTX code has evolved since the original implementation of the OSD it may be that this “fudge” is no longer required.
If requested, I can review both sides of the OSD implementation to determine the consequences of this PR, and to determine if any improvements could be made to better support the iNav OSD. For example, support of the canvas size MSP message.

I think this is worth considering for 8.0.0 even without a formal code investigation on the HDZero side. Because this fix is specific to regions of the OSD without any guardrails people would likely keep rediscovering the underlying lag issue if it still exists while they are attempting INAV updates and OSD changes.

more thoughts:
#8006 issue suggests to me that HDZeros OSD update rate at the time was horrible regardless of FC firmware. The timing of code changes makes me suspect HDZero users running pre v1.0.0 firmware would experience this old lag issue. I did investigate testing pre HDZero VTX v1.0.0 but I do not any VTX practical to test with lower than v1.3.0.